Parallel Routes

layout.ts内で、children以外のReactNodeを渡せる機能

childrenとは別に並列にroutingを作ってるとみなせる。だからparallel routes

例

app

hoge/fuga/page.ts

layout.ts

そのとき、layout.tsにそのReactNodeがchildrenとして渡される

app

@header/hoge/fuga/page.ts

hoge/fuga/page.ts

layout.ts

こうすることで、layout.ts内に引数経由で、headerというpropsが更に渡せる。childrenとは別に

素朴に考えると、普通にレイアウトコンポーネント上で、別コンポーネントをrenderすればいいだけだから、メリットが分かりにくい

layout.ts上でpathnameによる条件分岐が書けない

RSCは、サーバ上でレンダリングを行い、その結果のReactNodeをブラウザに渡す機能

これを、サーバ内で、サーバコンポーネント同士で行えるようにしたものが、Parallel Routes

並列してサーバコンポーネントをレンダリングすることができる

さらに、サーバコンポーネントとして分割したら、revalidateをかける際に、その分割単位で行える

For highly dynamic sections of an app, such as dashboards and feeds on social sites

レンダリング最適化に関わるもの

これのお陰でなんらかのクライアントサイドの開発体験、実装しやすさが上がるがるものではない

いや、ルーティングも考えるとちょっと違うんだよな

これによって分割したコンポーネントを条件によって出し分ける例として、Conditional Routesという名前がついている

code:ts

import { getUser } from '@/lib/auth'

export default function Layout({ params, dashboard, login }) {

const isLoggedIn = getUser()

return isLoggedIn ? dashboard : login

}

これは、サーバコンポーネント上で、ログインの確認をして、dashboardかログインかを出し分けているので

まずはRSCだから

ログイン処理をサーバ上で済ませている

不要なコンポーネントをクライアントにわたす必要がない

特定の要素をrevalidate書けたいときに便利？

しかし、parallel route内でルーティング入ってくるとかなり複雑になって良くない

default.jsの挙動とかが分かりにくい

RSCをやる場合、そのサーバコンポーネントをサーバ上で再レンダリングをしたい

revalidateとかで発火される

そのためには、再レンダリングしたいコンポーネント単位は、フレームワーク側で直接握れるべき

親階層より下にあると困る

はず

だから、わざわざfile based routingで別フォルダ、ファイルで定義させて、layout側でprops経由でinjectさせる

これはRSCである以上避けられないのでは？

一方で、slot（@itemみたいなの）の中でさらにルーティングができるようになっているやつは、やってることが複雑

同じslotが、異なるルーティングでどのようなcomponentになっているかを定義したいということになる

soft navigationとhard navigationで挙動が違うのも難しい

別概念のrouteと、pathの凝集、どちらがいいかという話かな

.next消して動くの遭遇した。カスすぎ